In the ethmac core (http://opencores.org/project,ethmac) there are lots of delayed assignments (a
There are wishes to remove these delayed assignment because they pollute the code, don't interface well with other cores that has no delays and they aren't translated into hardware, which means they can be seen only as a visual debugging aid. As a first step, I have exposed the Tp parameter to the top, so that anyone who instantiates the core can set the delay to 0. The regression tests have run successfully with Tp set to 1 (the default) and 0 (no delay)

The next step would be to remove them completely, but before I do that, I would like to hear any reasons for keeping them. Please notify me if I have overlooked something.

Best Regards,
Olof Kindgren
olof@opencores.org

Back in the early days of verilog we used to build flip flops using blocking (=) assignments and #delays were needed to get the correct behavior. Then along came non-blocking assignments and Synopsys told everybody to use them for flipflops but forgot to mention that you should also drop the #delay at the same time. A lot of people missed that and still kept adding #delays to non-blocking statements thinking that it actually did something.

There are some corner cases where if you mix behavioral code and backannotated gates then the #delays will give you the needed hold time but if you are doing that then you should add a wrapper. Do not expect the rtl code to handle it.

The opencores coding guidelines should be changed to not allow these.

Get rid of them.

John Eaton

I just read the coding guidelines, and they have this to say:

2. Strong Recommendation: Do not use delay elements.
It causes synthesis and timing verification problems.
If you use delay elements, you MUST consider worst and best case timing
and not be happy with the delay in nominal case. This will make your
core reuse unfriendly since it will have to be characterized for every
target technology/process.

On the other hand it says this a bit further down:

1. Strong Recommendation: Do not use statements such as �assign #X a
= b;� or �#X;� where X is a number of time units of delay.
These statements are meant primarily for simulation only. For flip-flop
models it is recommended that it is modeled with delay unit of 1.
Example always q
Do you suggest that we scrap the last two sentences there?

The general opinion seems to be that they should be removed

When you create synthesizable RTL you should never use a #delay. It should all be 100% behavioral code with no delays at all. We simulate that to prove that the design works by checking the state of every node on every clock tick.

After we synthesize we can rerun our sims on backannotated gates to verify that the node states still match. If not then we have a timing error.

If you are working with a target technology that has library modules with delays then these should be kept in a different directory than the rtl code. That way it is clear that if someone needs to port your design to another target that they only have to worry about those modules in the target directory. The rtl will never change.


"Strongly recommend" is to weak of a term. If you use #delays then anyone wanting to reuse you code will have to evaluate them to see if they will still work with their tools and technology. That is extra work that they should not have to perform. There is no one reason why design reuse is hard, it is a death by a thousand cuts and this is one of them.


John Eaton

Then I will remove them sometime next week. Doesn't seem to make anyone sad to see them go.

Best Regards,
Olof Kindgren